import { Link, Construction } from '@brillout/docpress'
import { projectInfo } from '../../utils'

**Help & Business Inquiries**

- <Link href="#how-can-i-reach-out-for-help" doNotInferSectionTitle />
- <Link href="#how-can-i-reach-out-for-business-inquiries" doNotInferSectionTitle />
- <Link href="#i-ve-difficulties-integrating-a-tool-can-i-get-help" doNotInferSectionTitle />

**Project**

- <Link href="#can-i-use-vike-in-production" doNotInferSectionTitle />
- <Link href="#will-vike-survive" doNotInferSectionTitle />
- <Link href="#can-i-use-vike-to-achieve-what-i-want" doNotInferSectionTitle />
- <Link href="#how-can-i-contribute-support-vike" doNotInferSectionTitle />

**Technical**

- <Link href="#what-are-these-cryptic-javascript-errors" doNotInferSectionTitle />
- <Link href="#why-is-css-leaked-to-other-pages" doNotInferSectionTitle />
- <Link href="#why-are-there-a-lot-of-http-requests-in-dev" doNotInferSectionTitle />


## How can I reach out for help?

On:
- <a href={projectInfo.discordInvite}>Discord</a> to get help from the community.
  > There aren't any rules and you can post what you want. That said, questions sometime don't get any answers on Discord, so we recommend reading the help guide to increase your chance of receiving valuable assistance (see the channel `#help-guide`). And please consider giving back by helping others!
- <a href={projectInfo.githubDiscussions}>GitHub Discussions</a> to get help from the Vike team.
  > On GitHub Discussions, if you follow [these rules](https://brillout.github.io/rules/), you'll always get a response from the Vike team.
- [GitHub Issues](https://github.com/vikejs/vike/issues) to report a bug or request a feature.


## How can I reach out for business inquiries?

Contact `brillout`:
 - Per email. (See email address at [github.com/brillout](https://github.com/brillout).)
 - Per PM on Discord. ([Join Vike's Discord](https://discord.com/invite/hfHhnJyVg8) => right-click on the picture of `brillout` => `Message`.)

> Don't reach out on Twitter as it has shown to be unreliable.

> Don't privately contact `brillout` for getting help unless you're a sponsor, see <Link href="#how-can-i-reach-out-for-help" doNotInferSectionTitle />


## I've difficulties integrating a tool, can I get help?

Yes, and you can use GitHub Discussions to get help from the Vike team, see <Link href="#how-can-i-reach-out-for-help" doNotInferSectionTitle />

If it turns out that your difficulties are because of Vike, then we consider this a blocker on Vike's side and we will prioritize resolving your issue.

In general, Vike <Link href="#can-i-use-vike-to-achieve-what-i-want">aims to be highly flexible</Link>, thus resolving blockers is very important to us (ideally by design and at least by helping).


## Can I use Vike in production?

Yes. Many companies, from small startups to large corporations, are using Vike in production in a wide range of scenarios.

Consider, for example, the use case of some of Vike sponsors:
 - [Alignable](https://www.alignable.com) (social network), using a bespoke React integration with their Ruby on Rails backend.
   ([Sponsoring `brillout`](https://github.com/AlignableUser#:~:text=www.alignable.com-,Sponsoring,-Achievements), the creator of Vike.)
 - [Contra](https://contra.com) (freelance market), large codebase (>150 routes) with a bespoke React rendering strategy and GraphQL integration using Relay.
   ([Sponsoring `brillout`](https://github.com/contra#:~:text=of%20this%20organization.-,Sponsoring,-Top%20languages).)
 - [Ecosia](https://www.ecosia.org) (search engine), migrating their entire frontend from Nuxt to Vike for a substantial performance increase.
   ([Sponsoring `vikejs`](https://github.com/Ecosia#:~:text=People-,Sponsoring,-Top%20languages).)
 - [Burda](https://www.burda-forward.de) (publishing house with online newspapers reaching half of the German population), migrating their fragmented tech stacks of multiple and diverse online newspapers into one unified bespoke framework using Vike and Solid.
   ([Sponsoring `brillout`](https://github.com/BurdaForward#:~:text=People-,Sponsoring,-Top%20languages).)


## Can I use Vike to achieve what I want?

Vike prides itself on being a highly adaptable frontend framework. See for example the <Link href="#can-i-use-vike-in-production">use case of some of Vike sponsors</Link>.

Vike supports all common use cases:
 - <Link href="/ui-framework">Any UI framework</Link> (React, Vue, Solid, etc.), <Link href="/integration">any UI tool</Link> (state management, data fetching, CSS framework, etc.).
 - <Link href="/pre-rendering#should-i-pre-render">Without backend</Link>, with <Link href="/server">any JavaScript backend</Link> (Express.js, Hono, Fastify, Adonis, Nest, Deno, Bun, etc.), or with other backends (Java, Ruby on Rails, etc.).
 - <Link href="/data-fetching-tools">Any data fetching tool</Link> (REST, RPC, GraphQL, etc.).
 - Optional <Link href="/ssr">Server-Side Rendering (SSR)</Link>, optional <Link href="/pre-rendering">pre-rendering (SSG)</Link>, and optional <Link href="/vercel#vite-plugin-vercel">Incremental Static Regeneration (ISR)</Link>.
 - Optional <Link href="/stream">HTML streaming</Link> (with <Link href="/streaming#progressive-rendering">Progressive Rendering</Link>).
 - <Link href="/deploy">Deploy anywhere</Link> (VPS, AWS, GCP, Cloudflare, Vercel, etc.).

A common source of blockers are bugs; Vike is also unique because we quickly fix bugs and, to this date, [we have been able to fix all bugs](https://github.com/vikejs/vike/issues?q=is%3Aissue+is%3Aopen+label%3A%22bug+%3Aboom%3A%22). We value clean abstractions and correctness, which significantly reduces potential bugs.

Beyond common use cases, Vike has been designed from the ground up to be flexible, so that it can fit special needs. You can use Vike to <Link href="/build-your-own-framework">Build Your Own Framework</Link>.

If you have a use case you aren't sure you can implement with Vike then <Link href="#how-can-i-reach-out-for-help">feel free to reach out</Link>.

> In general, Vike aims to be as less blocking as possible. If you run into a blocker then don't hesitate to reach out. See also: <Link href="#i-ve-difficulties-integrating-a-tool-can-i-get-help" doNotInferSectionTitle />


## Will Vike survive?

We are a group of passionate developers; working on Vike is the thrill of a lifetime and there is no reason for us to stop.

We're making significant progress on being able to financially sustain ourselfes.

> Without relying on investor money, but through sponsorships and upcoming innovative open source business models.
> Independence is paramount for keeping Vike a community-driven project with transparent interests that are well aligned with its users.

As a company, you can secure Vike's future by [sponsoring](https://github.com/vikejs/vike/issues/1350).


## How can I contribute/support Vike?

Contributions in forms of [code](https://github.com/vikejs/vike/issues/1349) or [sponsoring](https://github.com/vikejs/vike/issues/1350) are much welcome.


## What are these cryptic JavaScript errors?

Many cryptic errors come from CJS/ESM issues around npm packages that distribute invalid code, see solution at <Link href="/broken-npm-package" />.

> In general, we care a lot about crafting helpful error messages. But we don't control error messages coming from other tools.


## Why is CSS leaked to other pages?

With <Link href="/client-routing">Client Routing</Link>, when navigating from one page to another, the CSS of the previous page isn't removed. This means that any CSS loaded by the previous page will also apply to the next page. In other words: CSS cumulates upon page navigation.

For example:

```jsx
// /pages/terms/+Page.jsx

import './style.css'

export const Page = () => (
  <div id="#terms">
    <h1>Terms of Service</h1>
    <section>
      {/* ... */}
    </section>
  </div>
)
```

```css
/* /pages/terms/style.css */

/* ❌ Bad: the CSS selector `section` can apply to any page */
section {
  font-size: 0.8em;
}
```

Narrow down the CSS selector instead:

```css
/* /pages/terms/style.css */

/* ✅ Good: the CSS selector `#terms section` only applies to our terms page */
#terms section {
  font-size: 0.8em;
}
```

> If you use **Vue** with `.vue` files, then Vue already scopes the CSS for you: the CSS you define in a `.vue` file is guaranteed to apply only to the component defined in that `.vue` file.

> If you use **React** or **Solid**, then we recommend using inline styles and/or a CSS-in-JS library (or Tailwind), while minimizing CSS files. Inline style aren't global and, therefore, aren't leaky.

> **CSS is injected by Vite** in the form of `<style>` tags. If you're curious why Vite doesn't remove old `<style>` tags, consider that removing CSS is problematic during the transient state upon page navigation. (It would lead to [FOUC](https://en.wikipedia.org/wiki/Flash_of_unstyled_content) because there is no transaction primitive for DOM manipulation.) In general, regardless of Vite's behavior, it's a good practice to narrow down CSS selectors.


## Why are there a lot of HTTP requests in dev?

In development, you may observe a lot of HTTP requests fetching many JavaScript files.
That's because <Link href="/lazy-transpiling">Vite does lazy transpiling</Link>.

While it's true that doing a lot of HTTP requests slows down page load (and optimizing that aspect is on Vite's radar), Vite's lazy transpiling approach enables unparalleled development speed.
